从PDD薅羊毛事件想到DevOps那些事

如果不了解故事背景的，可以先看：

DevOps技术发达的今天，PDD薅羊毛事件本不应该发生。

• 原本就不该出现这种无门槛的优惠券（等同于送钱），就算一定要发这张优惠券，应该发给特定用户目标群，不该让同一个人能薅几十万羊毛；

• 即使业务需求没错，而是开发代码写错，测试也该发现；

• 即使测试没发现，上线后半夜突然爆发的流量也该被系统运维监控到；

• 即使系统运维监控不到，旁路实时资金风控系统也该检测到；

• 即使这些没有监控到，是不是运维值班人员人肉也该发现，不至于9小时后才被制止。

这种业务需求的实现，不仅需要开发（Dev）按业务需求实现与验证，而且在运维（Ops）那边应该有相应的防范机制和技术保障措施的。而昨晚PDD薅羊毛事件显示PDD没有这样的验证、防范机制，所以羊毛党能直接用猫池+脚本API进行批量自动操作，薅羊毛才能薅得这么快、这么多。

这其实不是一个问题，而是显示PDD在研发、发布、运维和风控方面的一系列问题，如需求评审和系统业务测试不到位、系统CI/CD机制有漏洞、缺乏良好的业务风险校验或控制环节、运维监控形同虚设，甚至人工监控可能也缺失。

 1. 从需求上看

这种无门槛的百元优惠券就不应该出现！如果为了发展新用户，送无门槛优惠券也是电商常用方法，但应该经过公司某部门审批、在系统内有限制（单张不得高于30元，这叫内禀业务规则），而且还有其它业务条件，如一人只能领一张，而且不能应用于虚拟物品（如电话费、Q币等）的消费。如果没有这些限制，就自然给羊毛党有可乘之机，他们自然就购买那些最具流通性、实时交易、实时变现的虚拟产品（Q币、话费等），例如Q币实时充值、实时7折优惠售出，很容易变现，况且很多羊毛党都有专门的洗白通道。

这类需求错误，产品经理或业务人员就不应该犯，即使犯了，开发和测试对需求的评审、实现和验证过程中也该发现。

 2. 从研发上看

开发实现这类“无门槛的百元优惠券”用户故事时，也会想想哪类用户角色会使用这类优惠券，并在代码中加以限制。如果是开发失误了，测试会发现。测试用例都是有前置条件的，或测试人员进行手工测试，也往往需要扮演不同角色进行业务功能的测试，自然也能发现这类问题。

如果是测试人员配置错了测试券，就自动上线了，那说明持续集成/持续交付（CI/CD）缺乏自动验证，或者说缺少一个Staging环境（相当于Beta环境）来验证新上线的特性。即使直接上到产品线，也需要在部署完之后进行快速测试。即使没有做部署验证，如果采用灰度发布，即使出问题，影响范围小，造成的损失也不会这么大。

3. 从运维上看

即使需求或研发某个环节出错了，错误的特性也上线了，在运维端也应该被监控系统发现。如发现各种异常：

• 在凌晨3点到6点时，系统有大量访问，流量快速上升…

• 不同账号出现大量同一收货手机号、同一收货地址、同一行为、同一IP地址、同一支付ID等；

• 某一虚拟商品被抢购，销量暴增；

• 某一类优惠券的使用量在快速增加…

• ……

这类异常数据或问题自然是不正常的事，会触发内部报警机制，运维人员在第一时间就能处理。但是这些监控策略或机制也没有，据说是研发人员上班看到并发异常的日志才发现的。

4. 题外话

某公众号谈到PDD 研发和运维团队不乐意修内功，而喜欢秀外功，因为内功不容易被看到、不容易体现KPI，而外功容易，甚至很多运营恨不得管羊毛党叫爸爸，跪求他们来薅，反正羊毛薅完，GMV是特别好看，亏损是公司的，绩效奖金和升职加薪是自己的，所以何苦来哉？

从此想到软件测试。真正做好测试分析、测试设计的业务测试，其实对公司很有价值，但不容易讲故事、不容易写入KPI，在外面找好的工作机会还少。这样许多测试人喜欢搞自动化测试、重复造轮子，测试效果却一般，但这毕竟容易讲故事、容易写入KPI，即使成本很大，对公司不一定是好事，但对测试工程师是好事，既有好的绩效，又提高了自己的能力，出去找工作更有竞争力。